home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
mac
/
hfpcktrn.hqx
/
HF Packet tutor
/
hf_packet.txt
< prev
next >
Wrap
Text File
|
1993-06-28
|
18KB
|
341 lines
A BRIEF TUTORIAL ON HF PACKET OPERATION
by Norm Sternberg, W2JUP
1. TNC PARAMETER VALUES
RULE 1: DON'T USE THE FACTORY DEFAULTS IN YOUR TNC
The values stored in your TNC's EPROMs are totally unsuitable for HF
packet operation; they are tailored for the average VHF case. Here is a
set of recommended "non-default" parameter values for general purpose HF
operation on 40, 20 and 15 meter packet operation.
MAXFRAME 1 to 2
PACLEN 32, 64 or 80
TXDELAY 40 or 50
FRACK 6, 7 or 8
MAXFRAME
Choose a lower setting for poor conditions, a higher value for better
conditions. We have very strong mathematical and experimental evidence
(papers by Phil Karn and others) that MAXFRAME 1 provides better long-
term throughput even on VHF!
If you send FOUR frames in one packet and the distant station ACKs only
frame #1, then you're going to resend frames #2, #3, and #4. If he ACKs
frames #2, #3 and #4 but bombs #1, you're going to resend all four of
them again anyway. What's the point in cluttering the channel with two,
three or four un-ACK'ed frames when the first one hasn't been accepted?
Each frame imposes a fixed "overhead" on the packet. This "overhead" is
the synchronization, timing, clocking, control and address information
stuff that you DON'T type; the stuff that makes the protocol work. The
simplest frame you can send has at least 19 bytes (152 bits) of overhead.
Each BIT of each BYTE is tested by the error correction process.
Unless you have a definite need to maintain a specific document format,
don't waste bandwidth inserting blank lines because you think it may
"look good" on the other station's screen. If you're operating in the
CONVERSE mode as most people tend to do, your packet frame is actually
sent by the CARRIAGE RETURN or ENTER key.
That single CR/LF you type to make a blank line creates a frame that has
exactly the same overhead as a frame that has 80 typed characters. This
"overhead" is the packet protocol stuff like the sync, callsigns and con-
trol information - stuff that you don't see, that conveys no "user" in-
formation. Every blank line must be ACK'ed just the same as the fully
typed lines. (It hurts to see a link time out retrying a blank line.)
PACLEN
Choose a lower setting for poor conditions, a higher value for better
conditions.
This is the number of typed characters that makes ONE frame. The lower
the number of characters or bytes in the frame, the higher the mathemat-
ical probabilities of getting through without taking a hit.
Each byte in the overhead mentioned above has eight bits. Each of the
characters you type has eight bits. If any one of those bits in any one
of those overhead bytes (or in your typed characters) takes a noise hit,
then the error correction process fails, and the whole frame is thrown
away.
Let's say that W2JUP is directly connected to W2HPM and sends the simple
line:
Hello, Joe, how are you?>>
That small packet frame actually consists of at least 20 bytes (160 bits)
of overhead, plus 27 bytes (208 bits) of your typed data, a total of 376
bits. If any one of those 376 individual bits is trashed at any point in
the link during transmission, then the entire frame is thrown away by the
receiving station.
Now let's assume that you're still using the factory-default value of
PACLEN, 128 bytes, and that you're NOT typing any CR/LF so that your TNC
is automatically sending the packet at your 129th typed character. Your
frame might look like this:
Joe, I wanted to let you know that I wouldn't be able to go to the club
meeting tomorrow night and you'll have to get a ride from
The same simple arithmetic tells us that you've just sent 20 bytes of
overhead, plus 128 bytes of the characters you've typed, resulting in a
frame that has 20 + 128 * 8 = 1184 bits.
Simple common sense says that the chances of getting 1184 bits through
the link "unharmed" - are much lower than getting only 376 bits through
without damage by the typical noisy HF radio environment. Now - if you
happen to be operating with the factory-default settings (as your TNC is
shipped from the factory):
MAXFRAME 4
FRACK 3
PACLEN 128
Let's look at MAXFRAME first. Arithmetic tells us that you've just sent
a packet of FOUR frames, each one containing 1184 bits, totalling 4736
bits. The chance of ALL 4736 bits surviving the journey in typical HF
conditions is a wee bit small.
We're limited by Part 97 to a maximum 300 bit-per-second data rate on HF
packet. At 300 bits per second, each BIT of each BYTE (or character) has
a duration of 3.3 milliseconds. You can see that it doesn't take much of
a noise pulse to smear one of those many bits and thereby kill an entire
frame. Have you ever measured the length of a single pulse from either
the "Woodpecker" or your local power line noise?
Now, let's look at FRACK. The FRACK timer sets the amount of time that
your TNC will wait for an ACK after the instant your PTT keys your rig.
Contrary to a common misunderstanding, FRACK time is NOT counted from the
end of your burst; it's counted from the beginning.
Let's assume you're still using the factory supplied default values
FRACK 3 (3 seconds)
TXDELAY 30 (300 milliseconds).
Let's say that you send our sample short line shown above:
Hello, Joe, how are you?>>
That packet frame contains 376 bits of stuff. More arithmetic:
376 bits @ 300 bits per second = 1.25 seconds
300 milliseconds TXDELAY = 0.30 seconds
Length of burst = 1.57 seconds
minus FRACK delay = 3.00 seconds
Available response window for ACK = 1.47 seconds
This appears to be logically possible - but is it really? Is this
enough time for the other station to send you the ACK you need?
The other station's TNC must send an ACK whose minimum length will be 20
bytes or 376 bits. If he's using a slightly lengthened TXDELAY (say 400
milliseconds, a longish DWAIT of 320 milliseconds, a RESPTIME of 5 (500
milliseconds), or if his TNC hears anything on the channel and delays the
ACK for even a few hundred milliseconds, we have an interesting problem.
Let's assume that the other station's TNC received a valid frame from
your system, the channel is clear, and his TNC is going to send the ACK
back to you. Now we've got a very cute "CATCH-22" situation:
376 bits @ 300 bits per second = 1.25 seconds
Distant station's TXDELAY = 0.40 seconds
Distant station's DWAIT = 0.32 seconds
Distant station's RESPTIME = 0.50 seconds
TOTAL DELAY before other station's end-of-data = 2.47 seconds
Remember that your system won't know if his ACK is valid until your TNC
has received and decoded his entire frame. The combined delays intro-
duced at his end now approach your FRACK time. You can't decode and val-
idate his ACK before your FRACK timer runs out. Your TNC RETRYs your
frame because the other station's ACK didn't arrive on time. And all
this relates to his sending an ACK frame of only 20 bytes.
Now that we've had a taste of timing concepts, let's see why HF packet
doesn't work and what happens if you're still using the factory-default
values:
MAXFRAME 4
PACLEN 128
FRACK 3
Our arithmetic said that you would send a packet of four frames, each one
containing 1184 bits, totalling 4736 bits.
4736 bits @ 300 bits per second = 15.79 seconds
300 milliseconds TXDELAY = 0.30 seconds
Length of burst = 16.09 seconds
FRACK delay = 3.00 seconds
Available response window for ACK = minus 13.09 seconds
You cannot fit a 16-second burst into a 3-second FRACK window. Your
FRACK timer expires before you've finished sending the packet! This is
not going to work!
Now, let's use the same arithmetic to see how our suggested values fit in
here.
MAXFRAME 1 (Only ONE un-ACK'ed frame allowed on the air)
PACLEN 64 ((64 * 8) + (20 * 8)) = 672 bits
FRACK 6 (6 seconds)
672 bits @ 300 bits per second = 2.24 seconds
300 milliseconds TXDELAY = 0.30 seconds
Length of burst = 2.54 seconds
FRACK delay = 6.00 seconds
Available response window for ACK = 3.46 seconds
This will work. Your single frame packet burst of 20 bytes of overhead
and 64 bytes of your typed data adds up to about 2.5 seconds. About 3.5
seconds remain available as the interval during which you must receive
the ACK from the other guy before your TNC will retry the frame.
Below 28 MHz you're limited to 300 bits per second. On VHF you've been
using 1200 bits per second. Everything on HF takes FOUR TIMES LONGER to
send, and FOUR TIMES LONGER to receive.
TXDELAY
Don't assume that TXDELAY relates ONLY to your radio's switching times.
It also relates to the switching and other timing factors in the other
station's radio. In our real world of HF packet radio, TXDELAY relates
to the radios at both ends of the link.
Nearly all phase-locked-loop synthesized radios have some measureable
"settling time". This delay is introduced by some PLL frequency setting
systems when switching from transmit mode to receive mode and vice-versa.
We also note that many HF transceivers have a significant delay - even
with "fast" AGC. This additional delay occurs while the receiver's AGC
circuit is "relaxing" and returning the receiver to full sensitivity.
One more cause of delays appears when the sending station uses AFSK in
the single-sideband mode. Some operators are not careful to avoid
driving the transmitter into ALC action. ALC (Automatic Level Control)
tends to reduce the transmitter's power output at keyup time and, if
excessive, can actually destroy the first few bytes of the transmitted
packet frame. Those first bytes of each packet frame are the FLAG field,
the information that marks the beginning of the frame and provides timing
or synchronization information to the other station's TNC. If the flag
is smeared during transmission, the receiving TNC can't use that frame
and throws away whatever it receives after it. In addition, the more
sync you have on the front of each frame, the higher the probability that
the other station's TNC will successfully decode your frame in conditions
of noise and propagation effects.
Extra flag also seems to help combat the effects of multipath and select-
ive fades. Don't fall for that "Too much TXD cuts down my throughput"
nonsense. If the other station doesn't decode your flag correctly, then
all the bytes after the sync are trashed; the frame is thrown away. So
much for your "throughput".
2. FREQUENCY CONTROL AND STABILITY
RULE 2: HF PACKET DEMANDS PRECISE OPERATING FREQUENCY CONTROL!!
You've operated VHF packet without problems, so you've probably ignored
your TNC's transmitted tones and calibration. You've probably devoted
the same benevolent neglect towards your TNC's demodulator calibration.
You connect to your buddies and to the local BBS; your rule has been "if
it ain't broke, don't fix it".
On FM, the the tones you receive are directly generated and controlled in
the other station's TNC and vice-versa. Your TNC's tones are transmitted
directly, unaltered, by your FM transmitter and received unaltered by the
other station's receiver. Your synthesized radio's LED frequency display
tells you you're on the same frequency as the other station.
But HF packet is a different story. The tones produced by your TNC may
no longer be the same tones that come out of the other station's radio.
The frequency of the tones recovered from the other station's receiver
depend on how the other station's operator tunes his receiver. Whether
you and the other station are using AFSK or direct FSK, the tones from
the receiver will always be determined by receiver frequency tuning.
Tuning accuracy on HF packet radio is generally more critical than in the
other operating modes. Tuning errors as small as 20 Hz can result in
failure to decode packets successfully. The more selective the receiver
and the TNC's filters, the more critical the tuning accuracy. Some IF
filters can be too narrow to handle data at our usual HF packet rate of
300 bits per second. In general, IF filter bandwidths should be greater
than 500 Hz for packet operation at 300 bits per second.
HF packet operation also imposes greater demands for overall transmitter
and receiver stability. Unless the rig can hold frequency, plus or minus
20 or 30 Hz for more than just a few minutes, you may drift right out of
a useable HF link and "die" from excessive retrys.
There are other interesting problems. Unlike conventional Baudot, ASCII
RTTY and AMTOR, packet signals use a data format called NRZI (non-return-
-to-zero-inverted), which in effect ignores data sense (mark-space polar-
ity). On HF packet, you can use upper sideband or lower sideband equally
well. The only difference will be in the frequency shown on your rig's
tuning display. You can be on USB while your link partner can be on LSB.
Your rigs will appear to be on different frequencies. In general, most
stations using AFSK tend to operate on LSB. It's best to use the same
sideband as the station you're working.
To set up a schedule, or connect to a PBBS, or link in a network system,
you can't always go strictly by the frequency displayed by most modern HF
rigs. There is no industry-wide standard as to the exact meaning of the
numbers shown. Some transceivers display the frequency of the suppressed
carrier in SSB; some show the frequency when your rig is tuned to Mark
(lower) tone, some show tuning for Space (higher) tone. Some HF rigs
even provide front-panel adjustment of the digital display to whatever
the user wishes; carrier, USB, LSB, FSK either tone, etc.
For the AFSK packet operator, this situation is somewhat complicated by
the lack of an industry-wide standard for HF Mark and Space tones. AEA's
PK-64 and PK-232 TNCs use 2110 Hz as Mark and 2310 Hz as Space, about in
the same range as the traditional RTTY tones at 2125 and 2295 Hz (plus
and minus 15 Hz).
Most licensed clones of the TAPR TNC-2 (including the AEA PK-80) use 1650
and 1850 Hz for Mark and Space respectively. TNCs using the AMD7910
"World Chip" modem (including AEA's PK-87 and PK-88) provide a choice of
1075 Mark and 1275 Space, or 2025 Mark and 2225 Space.
When using AFSK, your rig's displayed frequency will literally depend on
the tones being transmitted by the distant station, and also on the fre-
quencies to which your TNC's demodulator and filters are tuned. Check
your TNC and transceiver operating manuals to determine what audio tones
your TNC uses for Mark and Space, and how your rig's digital display re-
lates to the received and transmitted frequencies.
There are some subtle problems in HF packet radio. You may see lots of
interesting packet signals, send repeated connect requests - and nothing!
You check your timing parameters; they're all what they should be. You
set AGC to "FAST", you verify that "ALC" is not active. VOX is turned
off, the rig is putting out power, the antenna is connected, everything
appears "normal - and still nothing! What can be wrong here?
You've probably assumed that your rig is receiving and transmitting on
the same frequency shown by your digital display. This is not always
true! Some of the most-recent HF transceivers seem to have as much as
200 Hz difference between the receive and transmit frequencies. This is
enough to guarantee your inability to establish and maintain a decent
packet link. Don't assume anything! Be prepared to tweak your RIT/XIT
controls to make the link work. Be prepared to recalibrate your rig's
reference oscillators if neede. You may require either a good counter or
a patient partner to determine how your rig is behaving and if you're
really sending and receiving on the same frequency.
3. CONCLUSIONS
You too can work HF packet successfully. Remember these general
principles:
o Assume nothing
o Take nothing for granted
o Check everything twice
o Recognize that there are major operational differences between VHF
and HF packet radio.
o Remember the two most-critical factors for success on HF packet:
TIMING and TUNING
/30
W2JUP